【技术帖】使用KyBot寻找Apache Kylin离线构建瓶颈

提高Cube的构建效率可以有效降低数据更新的延迟，以及对集群资源的占用。本文将介绍如何使用KyBot寻找Cube构建过程的瓶颈，以及优化的思路和方向。

Apache Kylin是当今最流行的OLAP on Hadoop 分析引擎之一，它可以在PB规模数据集上取得亚秒级查询能力，帮助大数据分析师简单通过SQL或BI工具就能在大数据上进行交互式分析。

Apache Kylin的核心思想是通过构建Cube对原始数据进行预计算，以减小查询访问的数据量，从而减小查询的时间复杂度。提高Cube的构建效率可以有效降低数据更新的延迟，以及对集群资源的占用。本文将介绍如何使用KyBot寻找Cube构建过程的瓶颈，以及优化的思路和方向。

关于Cube构建

通常的，一次完整的Cube构建过程可能需要几分钟到几十分钟不等，具体时间取决于Cube设计的复杂度、数据量、集群计算能力、系统配置等。经过调优，Cube构建时间往往会大幅缩短，同时又不影响业务场景的查询性能，从而提高整个系统的执行效率。

构建Cube的任务包括一系列步骤，如生成Hive临时表、构建字典、生成Cube数据等，每一个步骤都是一个本地任务、Hive任务、MapReduce或Spark任务等，不同的任务依靠任务引擎进行调度。图1所示就是Apache Kylin中一个构建任务的截图。

图1 Cube构建任务（点击查看大图）

从图1中可以看出，每个步骤依次执行并具有一定的依赖关系，任何一步成为瓶颈都可能导致整个任务效率降低。如果想了解构建过程每一步的详情，可以参见引用文章[1]。

Apache Kylin官网和社区不乏一些构建调优的文章，但都需要管理员对Hadoop、Kylin有较为深入的理解，想要精准地定位瓶颈还需要访问Hive、MapReduce 等多个管理页面入手，这些无形中加大了调优工作的难度。

寻找构建瓶颈

KyBot (https://kybot.io) 是为Apache Kylin及其商业版KAP提供在线诊断、优化及服务的平台。通过分析Apache Kylin的日志等信息，为用户提供可视化仪表盘、系统优化、故障排查、知识库等自助式服务。

登录进入KyBot后，通过左侧菜单进入“任务”仪表盘，即可看到所有构建任务的指标统计，如图2所示。

图2 任务仪表盘（点击查看大图）

在仪表盘中，右侧的折线图可以直观地观察到某个Cube（或整体）的构建性能变化趋势，图中的Cube构建性能基本稳定，整体性能较好。下方列表展示了所有任务的基本信息，通过过滤和排序就可快速找到需要调优的任务（如最慢、MR Waiting最久等），并单击右侧“Tuning”按钮进入任务详情页面。

图3 任务详情页1（点击查看大图）

如图3所示，任务详情页主要包含了一个时间图，用于展现一个构建任务的生命周期。时间图中每一个泳道代表Cube构建中的一个步骤，并和右侧列表一一对应。通过观察时间在各个步骤的分布，就可以快速定位耗时较长的那些步骤，而这些步骤往往可能就是瓶颈所在。按照经验，往往可以从Cube设计、MapReduce等方面入手寻找瓶颈。

优化Cube设计

一个设计不良的Cube经常导致Cuboid数量过多，造成构建步骤激增，给集群的计算和存储资源带来压力，最终导致构建时间过长、膨胀率较大。而很多Cuboid常常是冗余或与实际需求不符的，通过调整Cube设计对这些无用Cuboid进行剪枝，会对构建效率带来较大的提升，同时又不影响对业务场景的契合度。关于Cube设计优化的原理可以参见引用文章[2]。

以图3为例，最慢的步骤是Extract Fact Table Distinct Columns、Build Cube In-Mem和Convert Cuboid Data to HFile，这些步骤都是在准备、生成和转换Cube数据，导致时间过长的原因可能是Cuboid数过多，如果需要进一步优化，可以跳转到Cube详情页对Cube设计进行优化，以减少Cuboid的数量。关于Cube调优的介绍可以关注引用文章[3]，在此不再赘述。

Map Reduce优化

除了优化Cube设计，瓶颈还有可能出自Map Reduce的任务执行上。如图4所示，这个构建任务中耗时最长的是Build Cube In-Mem一步，这是一个Map Reduce任务，可以进入该步骤的Map Reduce详情页作进一步分析。

图4 任务详情页2（点击查看大图）

进入Map Reduce任务详情页，如图5所示，同样也是一个时间图，每个泳道展示了Map Task和Reduce Task的生命周期，其中绿色代表Map，蓝色代表Reduce。从图中可以清晰看出Task的执行时间分布。图中Map和Reduce的泳道长度参差不齐，说明执行时间很不均匀，原因可能是数据分布不均导致的，右侧列表的Diagnostics部分通过分析对这一猜想进行了证实：Map和Reduce的数据分布的确不够均匀（最大值和中位数相差较大），可以通过调整输入数据分布的均匀度进行优化。

图5 Map Reduce任务详情页1（点击查看大图）

如图6展示的泳道中，任务开始执行前有几十秒的空白期，远超过任务执行的时间长度，说明任务调度占用了相当大的时间，可以通过调整Yarn资源调度进行优化。

图6 Map Reduce任务详情页2（点击查看大图）

如图7所示，这个任务包含了30个Reduce Task，但同一时刻最多只有2个Reduce Task并发执行，导致更多的Reduce排队，从而拉长了整个任务的时间。此时，任务并行度成为了瓶颈，可以通过调整Reduce参数或Yarn资源分配进行优化。

图7 Map Reduce任务详情页3（点击查看大图）

总结

本文着重介绍了如何使用KyBot快速定位Apache Kylin的构建瓶颈。加速Cube构建能够提高整个数据处理的效率，同时节省计算和存储资源，节省集群开销。为了更加高效地完成调优，使用KyBot是一个最简单的方法，未来的KyBot也会更加自动化和智能化，建议遇到相关问题的朋友们都来试一试。

引用文章

[1] Optimize Cube Build

http://kylin.apache.org/docs20/howto/howto_optimize_build.html

[2] Apache Kylin 深入Cube和查询优化

http://kyligence.io/zh/%E3%80%90%E6%8A%80%E6%9C%AF%E5%B8%96%E3%80%91apache-kylin-%E6%B7%B1%E5%85%A5cube%E5%92%8C%E6%9F%A5%E8%AF%A2%E4%BC%98%E5%8C%96/

[3] 论一个好Cube的养成

http://kyligence.io/zh/%E3%80%90%E5%85%A5%E9%97%A8%E3%80%91%E8%AE%BA%E4%B8%80%E4%B8%AA%E5%A5%BDcube%E7%9A%84%E5%85%BB%E6%88%90/

更多详情请点击阅读原文。

 "Apache and Apache Kylin are either registered trademarks or trademarks of The Apache Software Foundation in the US and/or other countries. No endorsement by The Apache Software Foundation is implied by the use of these marks."

您可能还会想看